Currently, the ScriptRunner part only works in conjunction with the TextEditor part, and is not intended to run independently. (Remember that TextEditor only runs on Power PC!) In order to run ScriptRunner, be sure to place the OSA PlugIn shared library in the "OpenDoc Shell Plug-Ins" folder within the Editors folder, and place the ScriptRunner shared library in the Editors folder.
Functionality
The TextEditor part needs to be active, either as a root document or embedded. To activate ScriptRunner, select the "Show ScriptRunner" item in the Tools menu of the TextEditor part. (Note: if this menu item is greyed out, close the document, delete the Text Editor Preferences file from the Preferences folder in the System folder, and reopen the document). A floating palette will appear containing the control buttons to compile and run scripts. When selecting one of these actions, the ScriptRunner retrieves the selected text from TextEditor and uses that as the script data. If no text is selected at this time, the TextEditor part returns its entire contents. After a script is executed, a floating result window will appear containing the result (or "< no result >"). The result value can be dragged to another part or to the desktop, as plain text data.
Project
The ScriptRunner project consists of several pieces: a data transfer extension, OSA plug-in, scripting palette extension, and the ScriptRunner part. The "ScriptRunner Mechanics" document provides an overview diagram of these components. The following describes each piece in more detail.
OSA Plug-In
The purpose of this OpenDoc plug-in is to create a name space and register the ScriptRunner agent object into it. This allows a client to retrieve the agent object from the name space and then acquire the scripting palette extension via the agent.
Scripting Palette Extension
This extension belongs to the ScriptRunner part, and allows clients to manipulate the scripting palette (eg. Hide, Show, Move). The palette extension provides an API for client parts, and passes all requests onto the ScriptRunner part.
ScriptRunner part
The ScriptRunner part provides the implementation for the floating palette window and result window. ScriptRunner is responsible for fulfilling the requests from the palette extension. An OSA helper object is utilized to invoke the OSA scripting capabilities. The palette is global, meaning that the same palette is used by all clients within one process.
Data/Text Transfer Extension
This extension provides data interchange capabilities between parts. The Text Transfer extension is a subclass of the Data Transfer Extension class and adds support for text-specific data. When a client registers itself as the current client through the palette extension, the ScriptRunner part retrieves the Text Transfer extension from the client to allow data interchange.
How To Build
ScriptRunner consists of two projects: OSAPlugIn and ScriptRunner. Note that the ScriptRunner part is "weak" linked against the AppleScriptLib. The client part should also "weak" link against the "ScriptRunner Agent.stub" and "ScriptRunner.stub" libraries in the event that they are not installed.
ScriptRunner Agent.stub
To create the stub library for the client part to link against, follow these steps:
1) Make a copy of the OSA PlugIn shared library
2) Rename the copy to "ScriptRunner Agent.stub"
3) Open the stub library in ResEdit
4) Open the 'cfrg' resource, change the Member Count to 1, and delete the second member.
Only the class name is needed to link against, otherwise duplicate errors will occur.
5) Save the resource.
ScriptRunner.stub
Follow the steps outlined above, using a copy of the ScriptRunner library which is renamed to "ScriptRunner.stub".
The Next Steps
1) Recording is not available in the 1.0 version of ScriptRunner. In order to capture the events within OpenDoc,, a part would need to either install a handler or install a dispatch module specifying that it wants to intercept high-level events, and then call the OSAStartRecording routine. Installing a handler into the part is recommended for performance reasons.
2) Ideally, it would be nice to handle errors by having the client highlight the range of text where the scripting error occurred.
